Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install DB and apply patches in a single layer #2594

Closed
wants to merge 4 commits into from

Conversation

thelateperseus
Copy link

The oracle-docker-images repository allows patches to be applied, but the resulting image size is doubled (see #1990). Instead, we would like to apply the patches in the same layer where the database binaries are installed.

I have applied this only to the 19c and 21c Dockerfiles since the other versions are either at or rapidly approaching end of life.

Changes:

  • Set SLIMMING to false to ensure that all files required for patching are present.
  • Copied patchDBBinaries.sh, runDatapatch.sh and savePatchSummary.sh from the extensions/patch directory.
  • Modified patchDBBinaries.sh to delete temporary files to reduce image size.
  • Added steps to builder stage in Dockerfile to copy the patches to the container and run the patchDBBinaries.sh script.
  • Added steps to Dockerfile to copy datapatch and lspatches scripts under $ORACLE_BASE.

The oracle-docker-images repository allows patches to be applied, but the resulting image size is doubled (see oracle#1990). Instead, we would like to apply the patches in the same layer where the database binaries are installed.

I have applied this only to the 19c and 21c Dockerfiles since the other versions are either at or rapidly approaching end of life.

Changes:
- Set SLIMMING to false to ensure that all files required for patching are present.
- Copied patchDBBinaries.sh, runDatapatch.sh and savePatchSummary.sh from the extensions/patch directory.
- Modified patchDBBinaries.sh to delete temporary files to reduce image size.
- Added steps to builder stage in Dockerfile to copy the patches to the container and run the patchDBBinaries.sh script.
- Added steps to Dockerfile to copy datapatch and lspatches scripts under $ORACLE_BASE.
@oracle-contributor-agreement
Copy link

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

@oracle-contributor-agreement oracle-contributor-agreement bot added the OCA Required At least one contributor does not have an approved Oracle Contributor Agreement. label Mar 21, 2023
@gvenzl
Copy link
Member

gvenzl commented Mar 21, 2023

Hi @thelateperseus, thanks a lot for your contribution! Please sign the Oracle Contributor Agreement outlined above for us to be able to consider this PR.

@thelateperseus
Copy link
Author

Hi @gvenzl, I signed the OCA yesterday, but it's still "Under review".

@oracle-contributor-agreement oracle-contributor-agreement bot added OCA Verified All contributors have signed the Oracle Contributor Agreement. and removed OCA Required At least one contributor does not have an approved Oracle Contributor Agreement. labels Mar 23, 2023
@thelateperseus
Copy link
Author

Hi @gvenzl, Looks like my OCA signature has been verified now.

@gvenzl
Copy link
Member

gvenzl commented Apr 18, 2023

Great, thanks a lot, @thelateperseus!

@yunus-qureshi, can you please review this PR, thanks!

@yunus-qureshi
Copy link
Member

@thelateperseus - We are evaluating this PR. Can you please address the lint issues.

@@ -37,7 +37,7 @@ LABEL "provider"="Oracle" \
"port.oemexpress"="5500"

# Argument to control removal of components not needed after db software installation
ARG SLIMMING=true
ARG SLIMMING=false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need a SLIMMING arg now as can easily find out if patches or one-offs are available and then decide to slim down or not without user needing to specify it

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed the SLIMMING arg and also the extensions/patches directory.

Lint issues have been fixed as requested in the PR. Also, the SLIMMING argument is no longer required, so it has been removed. Likewise, the patching extension is no longer required and has been removed.
The `runInstaller` command normally completes with exit code 6, which represents successful completion with warnings. Previously, the `runInstaller` command was not the last in the script, so the script's exit code was 0.

This change adds an explicit `exit 0` to restore the previous script exit code behaviour.
@thelateperseus
Copy link
Author

@yunus-qureshi, I believe I've fixed everything requested. Please let me know if I missed anything.

@aditya059
Copy link
Member

aditya059 commented Aug 17, 2023

Hi @thelateperseus

Thanks for your contribution but we are going with a different approach. I have raised a PR for the same.

There are some disadvantages of your PR:

  1. We have to build the container image from scratch every time we want to apply a release update or one-offs. By scratch, I mean we have to place the linux base image (LINUX.X64_193000_db_home.zip) and release update and/or one-offs in patch folder and run the build script (buildContainerImage.sh). This will increase the build time.
  2. We will not be able to extend (or patch) any previously build image (or patched image). E.g. Images in container registry cannot be patched with your PR.

@thelateperseus
Copy link
Author

Thanks @aditya059. I don't mind the approach taken as long as the resulting image size is reduced.

I assume you're referring to #2682. I tried using your branch to build a 19.3 image then patch it to 19.16. The 19.3 image was 7.9GB and the 19.16 image was 7.77GB, so it looks like it's working as expected.

@aditya059
Copy link
Member

Closing this PR as the other PR (#2682) is merged.

@aditya059 aditya059 closed this Aug 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
database OCA Verified All contributors have signed the Oracle Contributor Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants